Of course, many will say that this is not-and-not and writing for the web is needed only in PHP, well, or in one of the modern languages, Python, Ruby, Node.js, etc.

But the fact is that writing sites on an assembler is very useful, and with suitable tools it is easy and pleasant.

In fact, this statement was only a hypothesis. To prove or reject it, this spring I started writing a forum in assembler.

Previously, I already had a web application in assembly language - CMS for a small site. Only it works in the "one writes, many read" mode. At the same time, it uses the CGI interface and therefore "many" cannot be read at the same time either.

Terms of Reference

And so I decided to write a web application to:

1. Respect the principle of "read a lot - write a lot."
2. It worked very quickly and did not load the server.
3. Used very little memory, again not to load the server.
4. Worked on a cheap virtual hosting.

All these conditions are met by the web forum. Therefore, the choice stopped on him. The task looks like this:

Write a web forum that:

1. Uses the FastCGI interface to serve requests faster than CGI and so that there is no limit on the number of simultaneously running processes on the server (my hosting plan has such a limitation in 60 30 processes).
2. Uses a transactional database to store information in one place and so that several visitors can write at the same time.
3. The functionality must be sufficient to use the product in real life to communicate with users.
4. The forum view could be completely changed from the configuration. Skins are our everything. And not everyone can edit the code in assembler.

In addition to FastCGI, it was possible to use SCGI, which even looks a little simpler for implementation. It just turned out that my hosting company only supports FastCGI.

But I did not have to regret about it. It turned out that despite the complexity of the specification, FastCGI is very well suited for implementation on an assembler. So the code is simple and straightforward.

SQLite has been selected for the database. First of all, I know it very well and often use it in conjunction with an assembler. Secondly, using virtual hosting, I wanted the whole application to be located in the directories of the site, including the database. Thirdly, SQLite has the option "Full text search - FTS", which works quickly and will have to be very useful for searching the forum.

But there was a problem. I decided to write a forum on a 32-bit assembler for x86, so that you can work on both 32 and 64-bit servers. But the fact is that 64 bit servers, as a rule, do not provide 32 bit libraries. For the assembler, this is not important, but I also need 32 bit SQLite, but it needs the standard C library. But glibc (GNU C library) cannot be statically linked.

But the solution was found - to use the alternative library C - MUSL which has a dynamic linker, which can be placed in the application directory. An additional plus is the fact that the library is very small.

The implementation of the FastCGI interface was written so that it could be used in other projects.

For markup of forum posts, it was decided to use markdown like markup, which I had already written for CMS.

And so, what was the result?

I wrote in my free time. Sometimes at work, sometimes at home. The code, of course open . Distribution license: EUPL . The first version, saved on March 6, 2016 . Official version 1.0, saved on the 7th of April 2016 .

All of this took exactly 53 commits.

Since I know assembler, the most difficult thing during the work was ignorance of web protocols. I had to read the RFC documents about SMTP and FastCGI.

My web designer skills are not outstanding either, so it turned out the way it did. But since the entire design is in the configuration files, then replacing it is simple - there is no need to change the engine code.

Also, in the beginning I was completely unaware of the XSS attack and other aspects of web security. In the end, everything more or less expounded. Especially during the tests, which were conducted by some comrades from the Bulgarian forum. As a result, protection against bots appeared, as well as a topic in which there were 15,000 posts.

The application turned out very small. All files in the distribution of 1.8MB, from which 992KB SQLite and 622KB MUSL library. The application itself in assembler consists of a single file "engine", the size of 68.5KB (v1.2). Everything else - templates and images.

Installation is very simple - the archive is unpacked into the site directory and the '.httaccess' file is configured. Well or 'lighttpd.conf'. The site opens in a browser and an administrator user is created.

At runtime, the application uses approximately 2MB of RAM on the server, on the running process. Depending on the load, the apache server can run multiple instances of the process.

Unfortunately I can’t give you any comparisons with other forums, because data about the memory consumption of popular forums is not published (well, or I didn’t find it), but typical memory consumption, for example cpanel, is about 20MB for PHP process - about 10 times more.

The demo installation of the forum is available for visits and tests.

Hosting plan, which is a demo (the cheapest that I was able to take), virtual (shared). The limitations are as follows (according to the specification):

1. Single core CPU
2. 1GB RAM
3. 30 minutes of CPU time per day.
4. The maximum number of running processes is 60.

Slashdot effect test.

In August, quite by chance I managed to test the system on a real-time load. Someone (who did not understand who) posted a link to the code storage on Twitter. Several dozen reposted the link at once, and then published it in reddit and probably in other social networks.

Much to my regret, the link was to the code repository. And it works on CGI (fossil) and does not hold the load at all.

During the day, the forum was visited by several thousand visitors - about 8,000 to the code repository, which happily fell and got up (due to exceeding the limit of processes).

But a certain number of visitors (about 3000) still got to the forum and made more than 30,000 applications.

The forum did not feel the load at all and worked all the time without slowing down or losing applications. About 7 minutes of CPU time is used on this day.

Verdict hypothesis

I believe that all this hypothesis formulated at the beginning of my story, has been proven.

Web programming in assembler may not be very difficult, but the results are very good. As a result, such work greatly enhances the general culture of the developer and allows him to gain a deep understanding of the Internet protocols and how everything really works.

Using a web program in assembler can save on hosting and allow you to use cheap virtual hosting where others use dedicated servers and other expensive solutions.

Conclusion

Well that's all. If someone liked, use on health. Any kind of vulnerability and performance tests are very welcome. New code and bug fixes are accepted. New good skins are also very necessary.

And at the end of some links:

» Project code storage
» Demo installation
» How to download and install
» How to register without mail