I want to count views for a web page, while I am using G-WAN and C. I am not really so familiar with them. I am using Intel 64-bit processor. I have searched for the topic and still get no idea, can anyone help me? Thank you.
Asked
Active
Viewed 309 times
3 Answers
2
I know very little about G-WAN. I've been looking at their web site, and as far as I can tell it runs one thread per CPU; and your C code is loaded once, then executed in the context of a G-WAN thread each time its needed. In this case you should be able to use normal atomics (e.g. a suitable library for atomic operations for C, or inline assembly if you can't find a suitable library for C).
The problem would be storing your counter on disk (e.g. so that it doesn't reset to zero whenever the server is restarted). In theory, you only need to read the previous value once from disk when the web server is started, and write the new value to disk once whenever the server is stopped (or possibly once every 30 minutes or something in case the server crashes). It's not something on the critical path (e.g. not something that has to be stored/retrieved every time a page is served). In practice, I have no idea if G-WAN has any support for this at all (or if something like the atexit() function works).
If G_WAN has no support for it, you might be able to hack your way around it using (e.g.) a global "time when state was last saved" variable protected by some sort of mutex; where (if it's unset) you load the old state from disk and set the global variable, and if it is set you use it to determine if "X minutes" has passed since is was saved last. Of course acquiring a mutex and checking the global variable would have higher overhead than incrementing your counter; but it'd still be a several thousand times faster than (e.g.) using a database engine.
Brendan
- 35,656
- 2
- 39
- 66
-
G-WAN will not let you do that. The code is NOT persistent. G-WAN offers mechanisms to store data between connections, but it is outside of your control. Your code is indeed executed in a wrapper thread, but once the request is done, the thread is terminated. It will not sit tight waiting for another connection. Conceptually that would make no more sense than having a PHP program loop indefinitely, waiting to handle the next connection (which will likely not even be served on the same PC, depending on where the load balancing system will decide to handle it). – kuroi neko Jan 15 '14 at 14:02
-
@kuroi, you are wrong: The code IS persistant. Threads *do not exit* "after a request is done". Besides, G-WAN persistant pointers are persistant too. – Gil Jan 15 '14 at 14:32
0
I want to count views for a web page, while I am using G-WAN and C
Fine, there are several options:
- a G-WAN servlet
- a G-WAN connection handler
- a G-WAN content-type handler
...and your code can use different ways depending on your needs (listed in order of speed and memory efficiency):
- a global atomic variable attached to a G-WAN persistent pointer
- a global G-WAN KV store attached to a G-WAN persistent pointer
- a system shared memory segment (it will survive a server stop)
- an in-memory or disk-based database (SQLite, etc.)
- a DB KV store or server (Memcached, Redis, mySQL, etc.)
- etc.
You can even use a mix of these and use a fast (in-memory) method that is periodically stored to disk.
It really depends on your needs (is the counter tracking one single page? is it fetched 10,000 times per second, 1 million times? etc.).
Gil
- 3,279
- 1
- 15
- 25
-1
EDIT:
OK, my bad. I read the question too quickly and got a fixation on the HTTP requests, forgetting about the servlets. I thought of a simple hit counter on a page, hence my wondering at the use of an atomic variable.
Please accept my apologies.
Nevertheless, I don't see the point in optimizing a page counter, when serving the page itself will likely consume infinitely more CPU and resources than the read/modify/write of a single variable.
The KV system already provides a locking mechanism. As far as efficiency is concerned, using the kv_do primitive should handle concurrent accesses and get the job done in a neglectible amount of time.
And I rest my case about this atomic variables business.
Now that the multicore architecture imposes its constraints to about any application programmer,atomic variables seem like the latest trendy silver bullet around.
After spending a dozen years or so designing embedded, multitasking software where concurrent accesses and task synchronization is a constant concern, my conclusion is: they are not.
kuroi neko
- 8,479
- 1
- 19
- 43
-
Do you think there might be slight performance difference between (e.g.) something like a single `lock add [myPageCounter],1` instruction in assembly and using a database engine to increase a counter? – Brendan Jan 15 '14 at 03:04
-
The problem is ultimately to store your counter on a disk, so that the next instance of your code, running on another machine, will be able to read it again, increment it and write it back. The decisive factor here will be the time spent in the cloud file system. The time spent in your actual piece of code will be absolutely neglectible. Besides, this kind of architecture is not meant to write servers, simply to use C and whatever other languages to do the same job as PHP (plus a bit of streaming, maybe). Incrementing a counter will be lost in background noise. – kuroi neko Jan 15 '14 at 03:10
-
this answer actually added a lot of irrelevant stuff. The write-to-disk issue are of every system (which requires data persistence) in existence. There are plethora of in-memory databases developed to negate this barrier. And even if one must write to disk, there is always the periodic write option! I didn't see the OP mention anything I/O expensive in the question either - this answer just assumed that. – Nagi Jan 15 '14 at 05:34
-
@Nagi What the OP did mention is G-WAN. They are a web application server company. That is the execution environment they offer. Using C instead of PHP to generate web pages, and do a bit of streaming besides. Even though you might use C++ or a dozen other languages, your execution environment is basically the same as a PHP script's. There are no persistent memory context except the cache provided by the server framework, no in-memory DB you can control, and no periodic writes at your command. You suffer the I/O expensiveness inherent to web page servers. – kuroi neko Jan 15 '14 at 11:23
-
@kuroi, G-WAN is NOT *"using C instead of PHP to generate web pages" *as it supports both (and a dozen more). Further, your other statements are also wrong: *"There are no persistent memory context except the cache provided by the server framework, no in-memory DB you can control"*. G-WAN provides a persistent KV store, check its API: http://gwan.ch/api#kv and you can use any C/C++ library you wish to do so, including system shared memory that will survive a G-WAN stop and restart. – Gil Jan 15 '14 at 14:36
-
I said "C instead of PHP" just to make things clear about the context a C program was running in. The KV store is exactly the kind of things I had in mind when talking about server cache. You can save a lump of memory associated with a key, and get it back during the next connection. Still the control of this object is not in your hands, and you cannot create another such object from raw operating system primitives. Nevertheless, you have no persistent program running in this architecture. Only programs that can share memory easily between invokations. – kuroi neko Jan 15 '14 at 14:48
-
2@kuroineko there are ways to avoid disk I/O: offload your static content to a CDN, and cache your HTML template (for dynamic content generation). _"Nevertheless, you have no persistent program running in this architecture"_ Redis is a inferior option to G-WAN's KV in term of raw speed, standalone program, open source (if that's what you mean by _"in-memory DB you can control"_), and it does support periodic writes. Redis also has an official ANSI C client - you should be able to use it in G-WAN with a #pragma include. – Nagi Jan 16 '14 at 09:34